Different techniques have been developed for transporting information over a network, such as packet switching techniques whereby digitized data is arranged into so-called bit packets, and circuit switching techniques. In packet switching, bit packets may either be of fixed length like in the Asynchronous Transfer Mode (ATM) where the packets, also called cells, are all of a conventional fixed length, or be of variable length.
ATM has been recognized as the common base on which different types of services and networks can operate. The ATM technology can efficiently combine the transmission of speech, video, audio sound (what is commonly called multimedia traffic) and computer data into the wired network. Furthermore, ATM has proven to scale well from very high speed network infrastructure (the information highways) to customer premises networks. One of the great advantages of the ATM technology is the fact that it can guarantee some level of service when an ATM connection is set up. Such guarantees can correspond to transmission rate, transmission latency and information loss. They can be achieved mainly because the ATM architecture assumes that the transmission media are almost error free.
Before data are exchanged between a source Data Terminal Equipment (DTE) and a destination DTE, in an ATM network, a routing procedure takes place during which the Control Point of the entry border node determines the best route from the source DTE to the destination DTE. Afterwards, the origin Control Point (in the entry border node) sends a connection set-up message, a copy of is being delivered to the control point of every switching node on the route.
When the route has been established, a confirmation message is sent back to the entry border node which can then initiate the exchange of information between the source DTE and the destination DTE.
An ATM network generally uses the Private Network Network Interface (PNNI) protocol. In such a protocol, a Designated Transit List (DTL) containing the list of nodes and port identifiers defining the path from the source DTE to the destination DTE is added to the set-up message and is used as a route vector along the path.
When interconnecting an ATM network running the PNNI protocol with another network through an Interim InterSwitch Protocol (IISP) interface, no dynamic routing information is exchanged between the networks and it is impossible to use procedure such as Crankback (used in PNNI protocol) to ensure that a connection will be set-up even if a part of the other network is down.
When a set-up message is rejected through an IISP interface, there is no crankback information element in the clearing message (it is only defined on a PNNI interface). Therefore, only a regular call clearing message is received by the entry border node from the IISP interface. Such a clearing message only contains a cause information element. Furthermore, no retry is performed.
Several approaches have been used to remedy this type of problem. One solution consists in just doing nothing at all except waiting for the failing part of the network to recover. Of course, this solution is unacceptable because it may take a very long time. During that time many users cannot use the network.
Another approach is to get rid of IISP interface everywhere and to use PNNI protocol with the hierarchy everywhere. This is technically valid but it is almost impossible in the real-life environment for many reasons. First, not all products implement the PNNI protocol, while all of them implement the IISP. Second, a product may be able to implement the cases, but the PNNI protocol is a feature the customer has to pay for. The customer may not want to pay for it, may not want to change his network at all, and therefore may want to keep the IISP interfaces.
Still another approach consists in defining a new type of interface which would be an IISP-like with some extended feature which would solve the problem. This is not very good because it would be like some new proprietary protocol. In that case, this interface would not be compatible with current ATM Forum standards, and especially not compatible with the IISP interface. The consequence is that interoperability is completely jeopardized.
Accordingly, there is a need for a mechanism which extends the current standards procedures defined by the ATM Forum so that it becomes possible to solve the above problem cases without violating any standard procedure.